Today, security plays an important role in many electronic devices and computing environments. For example, conventional mobile electronic devices may be used for payment transactions which require that sensitive payment-related data, such as user credentials, are input and/or stored on said devices, Such mobile electronic devices may for instance be equipped with a near field communication (NEC) interface based on radio frequency (RF) technology, in order to exchange payment-related data with a terminal device at a point-of-sale was).
Traditionally, sensitive payment-related data have been incorporated into dedicated security tokens such as smart cards, in which the data are inherently confined to a relatively trusted environment. However, with the advent of integrated solutions, in particular the integration of so-called secure elements (SE's) in mobile devices, payment-related data are often exposed to a potentially hostile environment, and therefore the confidentiality of these data may be at stake.
A secure element is often implemented as an embedded chip, more specifically as a tamper-proof integrated circuit with (pre-) installed smart-card-grade applications, for instance payment applications, which have a prescribed functionality and a prescribed level of security. Examples of such secure elements are the integrated circuits of the so-called “SmartMX” or “SmartMX2” series of IC's produced by NXP Semiconductors. Alternatively, so-called Subscriber Identity Modules (SIM's) or Universal Subscriber Identity Modules (USIM's) may be used as secure elements. Furthermore, secure digital (SD) cards, such as traditional SD cards or micro-SD cards, may be used as secure elements.
However, in spite of their tamper resistance, secure elements that are integrated in multi-functional mobile devices are inherently less secure than dedicated smart cards, for example, and therefore there is a continuous effort to increase their security level. This problem is aggravated when so-called software-based secure elements are used. Contrary to the secure elements described above that are generally referred to as hardware-based secure elements and that still offer a relatively protected environment in which data may be stored and computations may be performed a software-based secure element is typically arranged to store sensitive data in a general storage unit (e.g. the main memory) of a mobile device. This storage unit is usually not security-proof. Therefore, developers of software-based secure elements face the challenge of embedding adequate security measures in these secure elements.
Some of these security measures have shown promising results. For example, the use of so-called obfuscated virtual machines (OVM's) appears to offer an acceptable level of protection against reverse engineering attacks. As described in the article “Hindering Reverse Engineering: Thinking Outside the Box” by Dube, T. E. et al., published in Security & Privacy, IEEE (Volume: 6, Issue: 2), in March-April 2008, a possible defense against so-called structure-centric attacks, i.e. attacks that aim at revealing a computer program's function, is based on the use of virtual machine logic, which implements a virtual architecture from a native instruction set. In order to further strengthen said defense, a virtual machine (VM) may be obfuscated. Therefore, a software-based secure element that comprises an obfuscated virtual machine (OVM) appears to offer a reasonable level of security. EP 2 482 184 A1 describes an adaptive obfuscated virtual machine. More specifically, it describes the generation of an obfuscated bytecode for execution in an adaptive VM execution environment. A VM compiler compiles a high level code to obtain the bytecode and applies a virtual instruction set architecture (V-ISA) definition to generate an optimized instruction combining two or more individual instructions in the bytecode. The VM execution environment is adapted to interpret and execute the optimized instruction.
However, a software-based secure element based on an OVM may still be susceptible to cloning. In particular, the OVM—in which cryptographic keys or other user credentials are stored—may be duplicated and used on an unauthorized mobile device, for example. In this case, the unauthorized mobile device might enable the same transactions as the original, authorized mobile device, which is clearly unacceptable. Thus, there still exists a need to improve the level of security offered by software-based secure elements of the kind set forth.